Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9704/000003_owner-urn-ietf _Wed Apr 2 14:05:28 1997.msg

Internet Message Format | 1997-04-30 | 7KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA23316
    for urn-ietf-out; Wed, 2 Apr 1997 14:05:28 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA23304
    for <[e-mail]>; Wed, 2 Apr 1997 14:05:25 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA19987  (mail destined for [e-mail]); Wed, 2 Apr 97 14:05:16 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA07352; Wed, 2 Apr 1997 13:05:03 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA14630; Wed, 2 Apr 1997 13:04:57 -0600 (CST)
Date: Wed, 2 Apr 1997 13:04:57 -0600 (CST)
Message-Id: <[e-mail]>
To: Leslie Daigle <[e-mail]>
Cc: Patrik Faltstrom <[e-mail]>, [e-mail]
Subject: [URN] Re: Hierarchical ownership of name spaces
In-Reply-To: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: [e-mail]

Leslie Daigle writes:
 > By your model, then, in order for ISBNs to be used in URN space, they
 > would have to be _assignable_ by some distributable, published
 > mechanism that ensures automatic assignment is unique (and satisfies
 > every other criterion that the _developers_ of that namespace have
 > for their own purposes).

ISBNs are already screwed up, I understand, since publishers are
forced to reuse IDs in their subspace when they run out of space.  The
problem, in my mind, is that they limited the size of the space rather
than making it hierarchically extensible.

But despite that flaw, ISBN ids *are* assigned by an established
mechanism (that doesn't quite ensure uniqueness) and corresponding
URNs would be assigned by the same mechanism, I would think.  I don't
see what you are getting at, or what you think my model is.

Any established name space will already have its own rules for
assignment of names, and the existence of corresponding URNs won't
change those rules.

 > I, however, have been operating on the assumption that URNs should be
 > globally and publicly _resolvable_, while perhaps only privately _assigned_.
 > I.e., I still can't assign an ISBN (URN) if I am not a publisher having
 > signed whatever necessary agreements.

I do not disagree.  Your "however" indicates that you think I do.
But, and you probably agree, some URN name spaces may be resolvable
only with limited access control.

 > The proposed work is to develop a system for globally unique, persistent
 > identifiers.
 >
 > If we have _no_ requirements that participating namespaces produces either
 > unique or persistent identifiers, then what's the point?

Good question.  If the only definition of what is unique is up to each
name space, and persistence, like life itself, eventually comes to an
end, then what possible enforcable requirements make any sense?

 > I agree that
 > it is difficult to _ensure_ that namespaces do adhere to this, but if
 > we don't even make the effort to require it, well...!

If we don't make the effort to require it, and there is not enough
incentive for the providers to provide it on their own, and users
don't care enough, well, why will anyone use it?  What are we really
trying to do?

My motivation for setting up the NAPTR mechanism, or any persistent
service, is to provide the service *if* people want it.  If they don't
want it, then why bother trying to force it on them with requirements?
The idea of requirements here is backwards.  We don't want to force
people to use URNs, we want to motivate them by providing a persistent
service that they will want to use.

It appears that the motivation behind the requirements is to protect
the "urn:" prefix as a brand name, as Dan Connolly suggested.  I agree
with him that this is ill advised.

 > > And you want to impose on the naming authority that they somehow avoid
 > > the hassles for the benefit of the world.  Doesn't the naming
 > > authority have a strong enough incentive without any external
 > > impositions?  Why will people choose to use URNs if they dont
 >
 > If the na doesn't want to do this -- htere are plenty of other mechanisms
 > for producing identifiers.  URLs, for example...  I hear they can
 > do virtually everything we're proposing for URNs...

But you don't believe it, of course.

As I've pointed out several times, the biggest problem with deploying
any new URI scheme is deploying the resolution mechanism.  If we can
deploy just one very general mechanism that is applicable not only to
names but any other kind of identifier, then this will be a great
benefit.  This is especially true if the mechanism also supports
greater persistence in the resolution process.

 > > understand the benefit of avoiding the hassles in the first place?
 > > But if they do, then why do we need to step in to impose our vision of
 > > order?
 >
 > Because some people _do_ feel the need for this order -- and that's
 > why they're participating in this process.

If the people who want the order think they can impose it on others
who are relatively satisfied with things as they are, then this is the
wrong market model - it won't happen that way.

Other people are involved in the process for other reasons.
I am here to provide a persistent resolution service that many people
will *want* to use, and not because there are any requirements on how
it is used.

 > > But indeed, it becomes very complex to decide whether the unique id
 > > rule is being obeyed.

 > Yes -- and I believe the NID requirements draft contains verbiage
 > to the effect that "different" is defined on a per namespace basis.
 > Namespaces may choose to delgate that decision furhter down the
 > food chain.

Great, but then what is the point of a baseline uniqueness requirement
that says only that "You MUST assign names uniquely, but you can
define 'uniquely' however you want"?

 > The difference is that I believe namespaces, _when_proposed_
 > as_URN_namespaces, should "agree" to adhere to some baseline
 > requirements.

But the baseline uniqueness requirement is meaningless.

I don't think there is a single requirement that could be enforcable
or meaningful.  So why do I worry about the imposition of
non-enforcable and meaningless requirements?  Good question.

Requirements that do make sense are at the level of protocol, not name
space management.

dan